Administrators of systems such as IBM's WebSphere® MQ protect their persistent data against loss or corruption caused by hardware or software failure or other problems by performing a “fuzzy” backup periodically. This involves taking a full backup of, for example, a database at time x and then continuing to record changes to the database in a log until the time when the next full backup is complete. Recovery is achieved by restoring from the backup and then replaying the log.
Some systems (for example WebSphere MQ) automate the backup process and this substantially improves usability. Automating the backup itself is relatively straightforward and is not addressed by this patent application. Determining the frequency at which such backups should be initiated is however more of a problem.
Various attempts at addressing this problem have been made. IBM have published the following at http://publib.boulder.ibm.com/infocenter/db2help/index.jsp?topic=/com.ibm.db2. udb.doc/admin/c0005955.htm: “If the amount of time needed to apply archived logs when recovering and rolling a very active database forward is a major concern, consider the cost of backing up the database more frequently. This reduces the number of archived logs you need to apply when rolling forward.”
Tivoli have published the following at http://webdocs.caspur.it/ibm/web/tsm-5.1/aix/html/winc/ans60073.htm:
“The Tivoli Storage Manager Backup and Restore windows provide an estimate function that estimates the amount of time required to process your files and directories. The estimated transfer is a rough calculation of the time it takes to transfer your data. This estimate is based on previous transfers of data between your workstation and the current Tivoli Storage Manager server. The actual transfer time could be longer or shorter than the estimate due to factors like network traffic, system load on your workstation, or system load on the server.
The Estimated Transfer Time is based on previous backup transfer rate, so you must run at least one backup operation first. The Estimated Transfer Time field reads N/A if no files are sent to or from the current Tivoli Storage Manager server. The estimate function also does not take into account whether or not files are excluded from backup. The assumption made by the estimation algorithm is that all the files selected will be sent to the server.”
Further Oracle's database documentation (http://www.doc.gold.ac.uk/oracle/doc/server.817/a76992/chx_inst.htm) details parameters to tune backup size and frequency and details of how to estimate recovery time for a given backup size. The documentation then goes on to detail how to adjust the recovery time to within your desired range.
Various patents/applications address the subject of backing up data. See for example U.S. Pat. No. 5,778,165 and US 2004/0098423.
The prior art does not however provide for an autonomic mechanism for determining the frequency at which data should be backed up.